Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/92mar/area.security.92mar.txt

Text File | 1993-02-17 | 8KB | 187 lines

Security Area

Director(s):


   o Steve Crocker:  [e-mail]


Area Summary reported by Steve Crocker

The Security Area within the IETF is responsible for development of
security oriented protocols, security review of RFCs, development of
candidate policies, and review of operational security on the Internet.

Much of the work of the Security Area is performed in coordination with
working groups in other areas.  The Security Area Advisory Group (SAAG)
is a group of security experts which provides both consulting help to
other areas and direct management of working groups within the Security
Area.

The main bulk of work for the SAAG consists of a set of formal work
items.  These work items correspond to four types of activities.


  1. Working groups within the IETF Security area.  These are marked as
     ``Security.''
  2. Working groups in allied organizations that function as part of the
     IETF Security area.  These are marked either ``PSRG'' for the
     Privacy and Security Research Group, or ``TSIG'' for working groups
     within the Trusted Systems Interoperability Group.
  3. Security relevant developments within working groups in areas other
     than security.  These are marked according to the relevant area,
     viz., Applications, Internet Services, Management, OSI, Operations,
     Routing, Standards, or User Services.
  4. Internal SAAG work items.  These are topics which do not merit the
     creation of a formal working group but which do need some level of
     attention.  These are assigned to a SAAG member and followed for
     one or more SAAG meetings.  These are marked as ``SAAG''.


The SAAG met during the first and last working group period of the San
Diego IETF. The first meeting was used to coordinate the activities for
the week and the second meeting was used to report on the activities
that have occurred.

During the week, of the twenty-two open work items on Monday, two work
items were closed and two new work items were opened.  The key
activities for the week to report are working groups and work items in
the security area:  SNMP Security, Common Authentication Technology,
Privacy Enhanced Mail, RFC 931 Revision, and Architectural Discussions.



                                   1





SNMP Security Working Group (SNMPSEC)

There were three documents, published in January 1992, which are
currently under consideration by the IAB.

Common Authentication Technology Working Group (CAT)

The basic idea is you have a set of applications that want access to one
or more authentication mechanisms, for example Kerberos or the
Distributed Authentication Security Service (DASS). There is a common
program interface, a General Security Services Application Program
Interface (GSS-API), that has been defined such that these applications
can be written to be neutral with respect to which mechanism is actually
employed.  The binding with a mechanism takes place at some later time,
currently compile time.  This raises the question of how two
applications each bound to a different mechanism would interoperate.  In
particular, if one peer supported Kerberos and the other peer DASS,
would they be able to authenticate each other?

This question was the principal focus of the meetings during this week.
Although the GSS-API was not designed with hybrid/common mechanism in
mind, it was discovered that it would support such an objective through
a number of different technical solutions.  Most of the meeting time
this week was spent identifying the requirements of a solution.  It is
believed that the objective is both technically feasible and achievable.

Privacy Enhanced Mail Working Group (PEM)

The specification of the key management infrastructure has been the
principal source of controversy during the last few meetings.  A revised
document was prepared and distributed prior to this meeting, and was
well received during this meeting.  Along with the three other documents
associated with PEM (Message Encryption and Authentication Procedures;
Algorithms, Modes and Identifiers; Key Certification and Related
Services), it will be submitted to the IESG by June in hopes of
achieving publication as a Proposed Standard by the Boston IETF.

The publication of the documents stabilizes the specifications and sets
the stage for the deployment of the Internet reference implementation of
PEM. A set of action items predicating the deployment of PEM were
identified and assigned.  These items include establishing the necessary
database mechanisms and software at the Internet Certification Authority
(ICA) for resolving distinguished name conflicts (this is necessary in
the absence of Directory Services), drafting an agreement to be used
between the ICA and the Policy Certification Authorities (PCA), and
facilitating the creation of PCAs (only one PCA proposal has been
submitted to the ICA for review; others are expected soon).  All of
these items are non-technical and do not effect the publication of the
specifications nor Beta testing the deployment of PEM, which is expected
to begin soon.



                                   2





RFC 931 Revision

RFC 931 is a specification of a protocol for a receiving peer of TCP
connection request to ask a server on the originating host of the
originating peer for an identifier associated with the originator of the
request.  The identifier would typically be the login name of the user
initiating the request.  This protocol was called an authentication
server.  As far as security is concerned, the value returned by the
server is only meaningful in the context of that host, and is
informational only since there are no assurances that a valid value is
being returned.

There is an effort to revise the document to tighten up the syntax of
the protocol and put it on the standards track.  In addition, a public
domain implementation exists that is currently being used by a modest
number of sites.

Previously this effort was being led by Dan Bernstein, the author of the
revised document and the implementation.  In order to give the protocol
the discussion it needs the effort has been restructured and a working
group created with Mike St.  Johns as the Chair, the author of the
original RFC 931.  In addition the revised protocol has been renamed to
be called the Identity Server to better reflect its functionality.

Architectural Discussions

The SAAG in its two meetings spent a significant about of time
discussing a security architecture for the Internet.  Since the Privacy
and Security Research Group (PSRG) is currently addressing the long-term
objective(s) in this area, the majority of the discussion focussed on
what the SAAG role could be in this area.

A number of action items were identified as a result of these
discussions.  First, Barbara Fraser from the CERT has agreed to draft a
document identifying some near-term security goals that the IETF, in
particular the SAAG, could be concerned about.  This will help to focus
SAAG discussions and guide interactions with working groups in other
areas.  We expect to have the document in time for discussions at the
Boston IETF SAAG meeting.

Second, two Birds of a Feather sessions will be scheduled at the Boston
IETF. One will be for Lower Layer Security and it will probably focus on
IP layer authentication and encryption, although some discussion about
the OSI TLSP and NLSP, and the SDNS SP3 and SP4 is expected.

The other BOF will be to discuss access control.  Given the existence of
authentication, in particular the strong authentication work of the CAT
Working Group, the next question is what to do with the knowledge that
you know who your peer is.

Finally, the routing area has received very little attention from
security to date.  With all of the activity in routing it has become
essential that the Security Area become much more directly involved.

                                   3





Radia Perlman will be the liaison to the SAAG for the routing area.  We
will be discussing a routing area security plan during our Boston
meeting.



                                   4